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DIMA GRIGORIEV AND VLADIMIR SHPILRAIN 

Abstract. We show that some problems in information security can be solved with- 
out using one-way functions. The latter are usually regarded as a central concept of 
cryptography, but the very existence of one-way functions depends on difficult con- 
jectures in complexity theory, most notably on the notorious "P 7^ NP" conjecture. 
This is why cryptographic primitives that do not employ one-way functions are often 
called "unconditionally secure". 

In this paper, we suggest protocols for secure computation of the sum, product, 
and some other functions of two or more elements of an arbitrary constructible ring, 
without using any one-way functions. A new input that we offer here is that, in 
contrast with other proposals, we conceal "intermediate results" of a computation. 
For example, when we compute the sum of k numbers, only the final result is known 
to the parties; partial sums are not known to anybody. Other applications of our 
method include voting/rating over insecure channels and a rather elegant and efficient 
solution of the "two millionaires problem" . 

Then, while it is fairly obvious that a secure (bit) commitment between two parties 
is impossible without a one-way function, we show that it is possible if the number 
of parties is at least 3. We also show how our unconditionally secure (bit) commit- 
ment scheme for 3 parties can be used to arrange an unconditionally secure (bit) 
commitment between just two parties if they use a "dummy" (e.g., a computer) as 
the third party. We explain how our concept of a "dummy" is different from a well- 
known concept of a "trusted third party". Based on a similar idea, we also offer an 
unconditionally secure k-n oblivious transfer protocol between two parties who use a 
"dummy" . 

We also suggest a protocol, without using a one-way function, for the so-called 
"mental poker", i.e., a fair card dealing (and playing) over distance. 

Finally, we propose a secret sharing scheme where an advantage over Shamir's 
and other known secret sharing schemes is that nobody, including the dealer, ends 
up knowing the shares (of the secret) owned by any particular player. 

It should be mentioned that computational cost of our protocols is negligible to 
the point that all of them can be executed without a computer. 



1. Introduction 

Secure multi-party computation is a problem that was originally suggested by Yao 
|18j in 1982. The concept usually refers to computational systems in which several 
parties wish to jointly compute some value based on individually held secret bits of 
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information, but do not wish to reveal their secrets to anybody in the process. For 
example, two individuals who each possess some secret numbers, x and y, respectively, 
may wish to jointly compute some function f(x,y) without revealing any information 
about x or y other than what can be reasonably deduced by knowing the actual value 
of f(x,y). 

Secure computation was formally introduced by Yao as secure two-party computa- 
tion. His "two millionaires problem" (cf. our Section [3|) and its solution gave way to a 
generalization to multi-party protocols, see e.g. [4], [7]. Secure multi-party computa- 
tion provides solutions to various real-life problems such as distributed voting, private 
bidding and auctions, sharing of signature or decryption functions, private information 
retrieval, etc. 

In this paper, we offer protocols for secure computation of the sum and product of 
three or more elements of an arbitrary constructible ring without using encryption or 
any one-way functions whatsoever. We require in our scheme that there are k secure 
channels for communication between the k > 3 parties, arranged in a circuit. We also 
show that less than k secure channels is not enough. 

Unconditionally secure multiparty computation was previously considered in [JJ and 
elsewhere (since the present paper is not a survey, we do not give a comprehensive 
bibliography on the subject here, but only mention what is most relevant to our paper). 
A new input that we offer here is that, in contrast with [JJ and other proposals, we 
conceal "intermediate results" of a computation. For example, when we compute a 
sum of k numbers nj, only the final result X^=i Ui ^ s known to the parties; partial sums 
are not known to anybody. This is not the case in [JJ where each partial sum Ylt=i n i 
is known to at least some of the parties. This difference is important because, by the 
"pigeonhole principle", at least one of the parties may accumulate sufficiently many 
expressions in m to be able to recover at least some of the other than his own. 

Here we show how our method works for computing the sum (Section [2]) and the 
product (Section 0J of private numbers. We ask what other functions can be securely 
computed without revealing intermediate results. 

Other applications of our method include voting/rating over insecure channels (Sec- 
tion and a rather elegant solution of the "two millionaires problem" (Section [3]). 

We also address another cryptographic primitive, known as (bit) commitment. In 
cryptography, a commitment scheme allows one to commit to a value while keeping it 
hidden, with the ability to reveal the committed value later. Commitments are used to 
bind a party to a value so that they cannot adapt to other messages in order to gain 
some kind of inappropriate advantage. They are important to a variety of cryptographic 
protocols including secure coin flipping, zero-knowledge proofs, and secure multi-party 
computation. See [8] or |13j for a general overview. 

It is known [12] that a secure (bit) commitment between two parties is impossible 
without some kind of encryption, i.e., without a one-way function. However, if the 
number of parties is at least 3, this becomes possible, as long as parties do not form 
coalitions to trick other party (or parties). It has to be pointed out though that formal 
definitions of commitment schemes vary strongly in notation and in flavor, so we have 
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to be specific about our model. We give more formal details in Section [6j while here 
we just say, informally, that what we achieve is the following: if the committed values 
are just bits, then after the commitment stage of our scheme is completed, none of the 
parties can guess any other party's bit with probability greater than ^. We require in 
our scheme that there are k secure channels for communication between the parties, 
arranged in a circuit. We also show that less than k secure channels is not enough. 

Then, in Section[7l we show how our unconditionally secure (bit) commitment scheme 
for 3 parties can be used to arrange an unconditionally secure (bit) commitment between 
just two parties if they use a "dummy" (e.g., a computer) as the third party. We explain 
how our concept of a "dummy" is different from a well-known concept of a "trusted 
third party" and also from Rivest's idea of a "trusted initializer" [15]. In particular, 
a difference important for real-life applications is that our "dummy" is unaware of the 
committed values. Also, our "dummy" is passive, i.e., he does not privately transmit 
information to "real" participants and he does not generate randomness. 

Based on a similar idea, we also offer, in Section [HJ an unconditionally secure k-n 
oblivious transfer protocol between two parties who use a "dummy" . 

In Section [9l we consider a related cryptographic primitive known as "mental poker" , 
i.e., a fair card dealing (and playing) over distance. Several protocols for doing this, 
most of them using encryption, have been suggested, the first by Shamir, Rivest, and 
Adleman [T7], and subsequent proposals include [5] and [9]. As with the bit commit- 
ment, a fair card dealing between just two players over distance is impossible without 
a one-way function since commitment is part of any meaningful card dealing scenario. 
However, it turns out to be possible if the number of players is k > 3. What we require 
though is that there are k secure channels for communication between players, arranged 
in a circuit. We also show that our protocol can, in fact, be adapted to deal cards to 
just 2 players. Namely, if we have 2 players, they can use a "dummy" player (e.g. a 
computer), deal cards to 3 players, and then just ignore the "dummy" 's cards, i.e., "put 
his cards back in the deck" . An assumption on the "dummy" player is that he cannot 
generate any randomness, so randomness has to be supplied to him by the two "real" 
players. Another assumption is that there are secure channels for communication be- 
tween either "real" player and the "dummy". We believe that this model is adequate 
for 2 players who want to play online but do not trust the server. "Not trusting" the 
server exactly means not trusting with generating randomness. Other, deterministic, 
operations can be verified at the end of the game; we give more details in Section I9.2L 

We note that the only known (to us) proposal for dealing cards to k > 3 players 
over distance without using one-way functions was published in [I], but their protocol 
lacks the simplicity, efficiency, and some of the functionalities of our proposal; this is 
discussed in more detail in our Section [TUJ Here we just mention that computational 
cost of our protocols is negligible to the point that they can be easily executed without 
a computer. 

Finally, in Section [TTl we propose a secret sharing scheme where an advantage over 
Shamir's [16] and other known secret sharing schemes is that nobody, including the 
dealer, ends up knowing the shares (of the secret) owned by any particular players. 
The disadvantage though is that our scheme is a (k, &)-threshold scheme only. 
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2. Secure computation of a sum 

In this section, our scenario is as follows. There are k parties Pi, . . . , P&; each Pj has 
a private element rii of a fixed constructible ring R. The goal is to compute the sum of 
all Hi without revealing any of the rii to any party Pj,j^i. 

One obvious way to achieve this is well studied in the literature (see e.g. [8, 9l 111]): 
encrypt each n, as E{rii), send all E(rii) to some designated Pi (who does not have a 
decryption key), have Pi compute S = ^ E(rii) and send the result to the participants 
for decryption. Assuming that the encryption function E is homomorphic, i.e., that 
^ E(rii) = E(J2i ni), each party Pi can recover £\ rii upon decrypting S. 

This scheme requires not just a one-way function, but a one-way function with a 
trapdoor since both encryption and decryption are necessary to obtain the result. 

What we suggest in this section is a protocol that does not require any one-way func- 
tion, but involves secure communication between some of the Pi. So, our assumption 
here is that there are k secure channels of communication between the k parties Pi, 
arranged in a circuit. Our result is computing the sum of private elements rii without 
revealing any individual rii to any Pj,j ^ i. Clearly, this is only possible if the number 
of participants Pi is greater than 2. As for the number of secure channels between Pi, 
we will show that it cannot be less than k, by the number of parties. 

2.1. The protocol (computing the sum). 

(1) Pi initiates the process by sending ri\ +noi to P2, where noi is a random element 
("noise"). 

(2) Each Pi, 2 < % < k — 1, does the following. Upon receiving an element m from 
Pi— l, he adds his rii + n 0i to m (where no« is a random element) and sends the 
result to Pj+i. 

(3) Pfe adds rik + n$k to whatever he has received from Pfc_i and sends the result 
to Pi. 

(4) Pi subtracts noi from what he got from P&; the result now is the sum S = 
J2i<i<k n i + Y J 2<i<k n M- Tnen p i publishes S. 

(5) Now all participants Pj, except Pi, broadcast their riQi, possibly over insecure 
channels, and compute X^2<i<fc n o«- Then they subtract the result from S to 
finally get Ei<;<fc n i- 

Thus, in this protocol we have used k (by the number of the parties Pi) secure 
channels of communication between the parties. If we visualize the arrangement as a 
graph with k vertices corresponding to the parties Pj and k edges corresponding to 
secure channels, then this graph will be a /c-cycle. Other arrangements are possible, 
too; in particular, a union of disjoint cycles of length > 3 would do. (In that case, 
the graph will still have k edges.) Two natural questions that one might now ask are: 
(1) is any arrangement with less than k secure channels possible? (2) with k secure 
channels, would this scheme work with any arrangement other than a union of disjoint 
cycles of length > 3? The answer to both questions is "no" . Indeed, if there is a vertex 
(corresponding to Pi, say) of degree 0, then any information sent out by Pi will be 
available to everybody, so other participants will know ri\ unless Pi uses a one-way 
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function to conceal it. If there is a vertex (again, corresponding to Pi) of degree 1, 
this would mean that Pi has a secure channel of communication with just one other 
participant, say Pi- Then any information sent out by Pi will be available at least to 
P2, so P2 will know n\ unless Pi uses a one-way function to conceal it. Thus, every 
vertex in the graph should have degree at least 2, which implies that every vertex is 
included in a cycle. This immediately implies that the total number of edges is at least 
k. If now a graph T has k vertices and k edges, and every vertex of T is included in 
a cycle, then every vertex has degree exactly 2 since by the "handshaking lemma" the 
sum of the degrees of all vertices in any graph equals twice the number of edges. It 
follows that our graph is a union of disjoint cycles. 

2.2. Effect of coalitions. Suppose now we have k > 3 parties with k secure channels 
of communication arranged in a circuit, and suppose 2 of the parties secretly form a 
coalition. Our assumption here is that, because of the circular arrangement of secure 
channels, a secret coalition is only possible between parties Pj and Pj+i for some i, 
where the indices are considered modulo k; otherwise, attempts to form a coalition (over 
insecure channels) will be detected. If two parties Pj and Pj+i exchanged information, 
they would, of course, know each other's elements rii, but other than that, they would 
not get any advantage if k > 4. Indeed, we can just "glue these two parties together", 
i.e., consider them as one party, and then the protocol is essentially reduced to that 
with k — 1 > 3 parties. On the other hand, if k = 3, then, of course, two parties together 
have all the information about the third party's element. 

For an arbitrary k > 4, if n < k parties want to form a (secret) coalition to get 
information about some other party's element, all these n parties have to be con- 
nected by secure channels, which means there is a j such that these n parties are 
Pj, Pj+i, ■ ■ ■ , Pj+ n -i, where indices are considered modulo k. It is not hard to see 
then that only a coalition of k — 1 parties Pi, ... , Pj-i, Pj+i, • • • , Pfc can suffice to get 
information about the Pj's element. 

2.3. Ramification: voting/rating over insecure channels. In this section, our 
scenario is as follows. There are k parties Pi, . . . , P&; each Pj has a private integer rij. 
There is also a computing entity B (for Boss) who shall compute the sum of all rij. The 
goal is to let B compute the sum of all rii without revealing any of the rii to him or to 
any party Pj,j ^ i. 

The following example from real life is a motivation for this scenario. 

Example 1. Suppose members of the board in a company have to vote for a project by 
submitting their numeric scores (say, from 1 to 10) to the president of the company. The 
project gets a green light if the total score is above some threshold value T. Members of 
the board can discuss the project between themselves and exchange information privately, 
but none of them wants his/her score to be known to either the president or any other 
member of the board. 

In the protocol below, we are again assuming that there are k channels of communi- 
cation between the parties, arranged in a circuit: Pi — > P2 —»...—>■ P^ — > Pi . On the 
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other hand, communication channels between B and any of the parties are not assumed 
to be secure. 

2.4. The protocol (rating over insecure channels). 

(1) Pi initiates the process by sending n\ + noi to P2, where noi is a random 
number. 

(2) Each Pi, 2 < i < k — 1, does the following. Upon receiving a number m from 
Pj-l, he adds his rii + no« to m (where noi is a random number) and sends the 
result to Pj+i. 

(3) Pfc adds n& + not to whatever he has received from Pk-i and sends the result 
to B. 

(4) Pfc now starts the process of collecting the "adjustment" in the opposite direc- 
tion. To that effect, he sends his nofc to Pk-i- 

(5) Pfe_i adds n (fc_i) and sends the result to Pk-2- 

(6) The process ends when Pi gets a number from P2, adds his noi, and sends the 
result to B. This result is the sum of all no«. 

(7) B subtracts what he got from Pi from what he got from Pj.; the result now is 
the sum of all n,, 1 < i < k. 

3. Application: the "two millionaires problem" 

The protocol from Section [21 with some adjustments, can be used to provide an 
elegant and efficient solution to the "two millionaires problem" introduced in |18j : 
there are two numbers, n\ and ri2, and the goal is to solve the inequality n\ > n2? 
without revealing the actual values of n\ or 112- 

To that effect, we use a "dummy" as the third party. Our concept of a "dummy" is 
quite different from a well-known concept of a "trusted third party" ; importantly, our 
"dummy" is not supposed to generate any randomness; he just does what he is told to. 
Basically, the only difference between our "dummy" and a usual calculator is that there 
are secure channels of communication between the "dummy" and either "real" party. 
One possible real-life interpretation of such a "dummy" would be an online calculator 
that can combine inputs from different users. Also note that in our scheme below the 
"dummy" is unaware of the committed values of n\ or n,2, which is useful in case the 
two "real" parties do not want their private numbers to ever be revealed. This suggests 
yet another real-life interpretation of a "dummy" , where he is a mediator between two 
parties negotiating a settlement. 

Thus, let A (Alice) and B (Bob) be two "real" parties, and D (Dummy) the "dummy" . 
Suppose A's number is n±, and B's number is 112. 

3.1. The protocol (comparing two numbers). 

(1) A splits her number n\ as a difference n\ = nf — n^. She then sends nj" to B. 

(2) B splits his number 712 as a difference ri2 = n\ — n^. He then sends to A. 

(3) A sends nf + to D. 

(4) B sends n\ + to D. 
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(5) D subtracts (nj + n 1 ) from (nj + n 2 ) to get rii — ri2, and announces whether 
this result is positive or negative. 

Remark 1. Perhaps a point of some dissatisfaction in this protocol could be the fact 
that the "dummy" ends up knowing the actual difference n\ — ni, so if there is a leak of 
this information to either party, this party would recover the other's private number n^. 
This can be avoided ifn\ and n<i are represented in the binary form and compared one bit 
at a time, going left to right, until the difference between bits becomes nonzero. However, 
this method, too, has a disadvantage: the very moment the "dummy" pronounces the 
difference between bits nonzero would give an estimate of the difference n\ — n<i to the 
real parties, not just to the "dummy". 

We note that the original solution of the "two millionaires problem" given in [18j . 
although lacks the elegance of our scheme, does not involve a third party, whereas our 
solution does. On the other hand, the solution in [18] uses encryption, whereas our 
solution does not, which makes it by far more efficient. 



4. Secure computation of a product 

In this section, we show how to use the same general ideas from Section [2] to se- 
curely compute a product. Again, there are k parties Pi, . . . , Pj-\ each Pi has a private 
(nonzero) element ni of a fixed constructible ring R. The goal is to compute the prod- 
uct of all ni without revealing any of the nj to any party Pj,j ^ i- Requirements on 
the ring R are going to be somewhat more stringent here than they were in Section [2J 
Namely, we require that R does not have zero divisors and, if an element r of R is a 
product a ■ x with a known a and an unknown x, then x can be efficiently recovered 
from a and r. Examples of rings with these properties include the ring of integers and 
any constructible field. 

4.1. The protocol (computing the product). 

(1) P\ initiates the process by sending n\ -noi to P2, where noi is a random nonzero 
element ("noise"). 

(2) Each Pi, 2 < i < k — 1, does the following. Upon receiving an element m from 
Pi-i, he multiplies m by n« • uqi (where noi is a random element) and sends the 
result to Pi+i. 

(3) Pk multiplies by ■ nofc whatever he has received from P^—i and sends the 
result to Pi. This result is the product P = ili<j<fc n, • il2<j<fc noi- 

(4) Pi divides what he got from P& by his noi; the result now is the product 
P = ni<j< fc Hi ■ il 2 <j<fc n 0i . Then Pi publishes P. 

(5) Now all participants Pi, except Pi, broadcast their no«, possibly over insecure 
channels, and compute il2<j<fc noi- Then they divide P by the result to finally 
get IIi<j< fc ni. 
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5. Secure computation of symmetric functions 

In this section, we show how our method can be easily generalized to allow secure 
computation of any expression of the form Yli=i n h w here rtj are parties' private num- 
bers, k is the number of parties, and r > 1 an arbitrary integer. We simplify our 
method here by removing the "noise", to make the exposition more transparent. 

5.1. The protocol (computing the sum of powers). 

(1) Pi initiates the process by sending a random element no to P 2 . 

(2) Each Pi, 2 < i < k — 1, does the following. Upon receiving an element m from 
Pi— l, he adds his n^ to m and sends the result to Pj+i. 

(3) Pk adds his rf k to whatever he has received from Pk-i and sends the result to 
Pi- 

(4) P\ subtracts (no — n\) from what he got from P&; the result now is the sum of 
all <, 1 < i < k. 

Now that the parties can securely compute the sum of any powers of their m, they 
can also compute any symmetric function of rii. However, in the course of computing 
a symmetric function from sums of different powers of n,, at least some of the parties 
will possess several different polynomials in m, so chances are that at least some of the 
parties will be able to recover at least some of the n^. On the other hand, because of 
the symmetry of all expressions involved, there is no way to tell which rii belongs to 
which party. 

5.2. Open problem. Now it is natural to ask: 

Problem 1. What other functions (other than the sum and the product) can be securely 
computed without revealing intermediate results to any party? 

To be more precise, we note that one intermediate result is inevitably revealed to 
the party who finishes computation, but this cannot be avoided in any scenario. For 
example, after the parties have computed the sum of their private numbers, each party 
also knows the sum of all numbers except his own. What we want is that no other 
intermediate results are ever revealed. 

To give some insight into this problem, we consider a couple of examples of computing 
simple functions different from the sum and the product of the parties' private numbers. 

Example 2. We show how to compute the function f(ni,ri2,ns) = nin 2 + n2n3 in 
the spirit of the present paper, without revealing (or even computing) any intermediate 
results, i.e., without computing nin 2 or n2n%. 

(1) P2 initiates the process by sending a random element no to P3. 

(2) P3 adds his to no and sends + no to P\ . 

(3) Pi adds his n\ to no + 113 and sends the result to P2. 

(4) P2 subtracts no from no + n3 + ni and multiplies the result by ri2- This is now 
nin 2 + n 2 n 3 . 
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Example 3. The point of this example is to show that functions that can be computed 
by our method do not have to be homogeneous (in case the reader got this impression 
based on the previous examples). 

The function that we compute here is /(rii, 77.2,^3) = n±n2 + g(ns), where g is any 
computable function. 

(1) Pi initiates the process by sending a random element a$ to P2. 

(2) P2 multiplies clq by his n2 and sends the result to P3. 

(3) P3 multiplies oqH2 by a random element cq and sends the result to P\. 

(4) Pi multiplies oqU2Cq by his n\, divides by ao, and sends the result, which is 
nin2CQ, back to P3. 

(5) P3 divides n\U2CQ by cq and adds g{n^), to end up with n\n2 + gin?). 

Note that in this example, the parties used more than just one loop of transmissions 
in the course of computation. Also, information here was sent "in both directions" in 
the circuit. 

Remark 2. Another collection of examples of multiparty computation without revealing 
intermediate results can be obtained as follows. Suppose, without loss of generality, that 
some function f(n\, . . . , n^) can be computed by our method in such a way that the last 
step in the computation is performed by the party P\, i.e., P\ is the one who ends up with 
f(n±, . . . , rifc) while no party knows any intermediate result g(ni, . . . , rtf.) of this compu- 
tation. Then, obviously, P\ can produce any function of the form F(n\, f(ni, . . . , n^)) 
(for a computable function F) as well. Examples include n\ + n\n2 • ■ ■ n& for any r > 0; 
n'i + (n\U2 + nz) s for any r, s > 0, etc., etc. 

6. (Bit) commitment 

While it is fairly obvious that a secure (bit) commitment between two parties is 
impossible without a one-way function, we show here that it is possible if the number 
of parties is at least 3. Generalizing the standard concept (see e.g. [8]) of a two-party 
(bit) commitment scheme, we define an n-party (bit) commitment scheme to be a two- 
phase protocol through which each of the n parties can commit himself to a value such 
that the following two requirements are satisfied: 

(1) Secrecy: at the end of the commitment phase, none of the n parties gains any 
information about any other party's committed value. 

(2) Unambiguity: suppose that the commitment phase is successfully completed. Then, 
if later the parties perform the decommitment phase (sometimes called the reveal phase) , 
each party's committed value can be recovered (collectively by other parties) without 
ambiguity. 

To make our ideas more transparent, we start with the simplest case where there are 
just 3 parties: Pi, Pj, and P3, and no two of them form a coalition against the third 
one. Suppose they want to commit to integers m, n2, and 713 (modulo some m > 2), 
respectively. More precisely, the scenario is as follows. During the commitment phase, 
the parties exchange various pieces of information about their integers rij. After that, 



10 



SECRECY WITHOUT ONE-WAY FUNCTIONS 



the parties "decommit" , or reveal, their integers and prove to each other that the 
integers m that they revealed are the same that they committed to. 
All computations below are performed modulo a fixed integer m > 2. 

(1) Each participant Pj randomly splits his integer rij in a sum of two integers: 
n i = r i + Si. If the participants want to commit to bits rather than integers, 
then Pi would split the "0" bit as either 0+0 or 1+1, and the "1" bit as either 
0+1 or 1+0. 

(2) (Commitment phase.) Pi sends t\ to P2, then P2 sends r\ + ri to P3, then P3 
sends T\ + T2 + r^ to P\ . In the "opposite direction" , P3 sends S3 to P2 , then 
P2 sends S2 + S3 to Pi, then Pi sends si + S2 + S3 to P3. 

After the commitment phase, Pi has si, S2 + S3, n, and r\ + r2 + r% 
(therefore also T2 + r%), so he cannot possibly recover any rtj other 
than his own. (He can recover 712 + ^3, but this does not give him any 
information about either or ^13). Then, P2 has S2, S3, n, and r2, so 
he, too, cannot possibly recover any m other than his own. Finally, P3 
has S3, rs, r\ + r2, and s\ + S2 + S3 (therefore also s\ + 82), so he, too, 
cannot possibly recover any 7ij other than his own, (He can recover 
n i + n 2, but this does not give him any information about either n\ 
or 712). 

(3) (Decommitment phase starts.) Note that during the decommitment steps below, 
each participant transmits information that somebody else had committed to 
before. This way, each piece of transmitted information can be corroborated 
by two parties, which prevents cheating since we are assuming that no two 
participants form a coalition. 

(4) P3 sends m + 112 to both Pi and P2. Now Pi knows 712, and P2 knows n\. 

(5) P2 sends t\ to P3. Now P3 can recover r2 from r\ and v\ + r%. 

(6) Pi sends S2 + S3 to P3. Now P3 can extract S2 from this sum, and then, since 
he has r2, recover n-2, and then also m since P3 already knows n\ + ni- 

(7) Pi sends n + r2 + r$ to P2. Now P2 can recover and therefore 113 = + S3. 

This protocol can be obviously generalized to 3m participants for arbitrary m > 1 
by splitting the players into triples and applying the above protocol to each triple. It 
can also be generalized to an arbitrary number k > 3 of participants with a circular 
arrangement of k secure channels, but we leave details to the reader. 

Remark 3. A question that one might now ask, if only out of curiosity, is: would this 
scheme work with any arrangement of secure channels other than a union of disjoint 
circuits of length > 3? The answer to this question is "no". Indeed, if in the graph 
of secure channels there is a vertex (corresponding to Pi, say) of degree 0, then any 
information sent out by P\ will be available to everybody, so other participants will 
know n\ unless P\ uses a one-way function to conceal it. If there is a vertex ( again, 
corresponding to P\) of degree 1, this would mean that P\ has a secure channel of 
communication with just one other participant, say Pj. Then any information sent out 
by Pi will be available at least to P2, so P2 will know n\ unless P\ uses a one-way 
function to conceal it. So, every vertex in the graph should have degree at least 2, which 
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implies that every vertex is included in a circuit. It follows, in particular, that the total 
number of secure channels should be at least k, by the number of participants. 

7. (Bit) commitment between two parties 

Now we show how our unconditionally secure commitment scheme for 3 parties from 
Section [6] can be used to arrange an unconditionally secure commitment between just 
two parties. This is similar, in spirit, to the idea of Rivest |15| . where an extra par- 
ticipant is introduced to bring the number of parties up to 3. However, an important 
difference between our proposal and that of |15] is that the extra participant in [15] is 
a "trusted initializer" , which means that (i) he is allowed to generate randomness; (ii) 
he can transmit information to "real" participants over secure channels. 

By contrast, our extra participant is a "dummy", i.e., (i) he is not allowed to gen- 
erate randomness; (ii) he can receive information from "real" participants over secure 
channels and perform simple arithmetic operations. 

One possible real-life interpretation of such a "dummy" would be an online calculator 
that can combine inputs from different users. Also note that in our scheme below the 
"dummy" is unaware of the committed values, which is useful in case the two "real" 
participants do not want their commitments to ever be revealed to the third party; 
for example, such a "dummy" could be a mediator between two parties negotiating a 
divorce settlement. 

Thus, let A (Alice) and B (Bob) be two "real" participants, and D (Dummy) the 
"dummy". Suppose A and B want to commit to integers n\ and n^, respectively. 

(1) A and B randomly split their integers rii in a sum of two integers: m = ri + Sj. 

(2) [Commitment.) A sends s\ to B, and B sends r2 to A. Then, A sends r% + r2 
to D, and B sends s± + S2 to D. 

(3) (Decommitment.) D reveals n + ri + s\ + S2 = n\ + n2 both to A and B. 

(4) Now A knows (n\ + ri2) —n\ = ri2, and B knows (ri-i+n^) ~~ n 2 = n i, so cheating 
by either party is impossible. 

8. k-n oblivious transfer 

An oblivious transfer protocol is a protocol by which a sender sends some informa- 
tion to the receiver, but remains oblivious as to what is received. The first form of 
oblivious transfer was introduced in 1981 by Rabin [H]. Rabin's oblivious transfer was 
later shown to be equivalent to "1-2 oblivious transfer"; the latter was subsequently 
generalized to 1-n oblivious transfer and to k-n oblivious transfer [3]. In the latter 
case, the receiver obtains a set of k messages from a collection of n messages. The 
set of k messages may be received simultaneously ( "non-adaptively" ) , or they may be 
requested consecutively, with each request based on previous messages received. All 
the aforementioned constructions use encryption, so in particular they use one-way 
functions. The first proposal that did not use one-way functions (and therefore offered 
unconditionally secure oblivious transfer) appeared in the paper by Rivest [15] that we 
have already cited in our Section [7J 
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In this section, we offer an unconditionally secure k-n oblivious transfer protocol that 
is essentially different from that of Rivest in a similar way that our bit commitment 
protocol in Section [7] is different from Rivest 's unconditionally secure bit commitment 
protocol [15]. More specifically, the extra participant in [15] is a "trusted initializer", 
which means, in particular, that (i) he is allowed to generate randomness; (ii) he can 
"consciously" transmit information to "real" participants over secure channels. 

By contrast, our extra participant is a "dummy", i.e., (i) he is not allowed to gen- 
erate randomness; (ii) he can receive information from "real" participants over secure 
channels, but he transmits information upon specific requests only. 

Again, let A (Alice) and B (Bob) be two "real" participants, and D (Dummy) the 
"dummy", e.g., a computer. Suppose A has a collection of n messages, and B wants to 
obtain k of these messages, without A knowing which messages B has received. Suppose 
that all messages are integers mi, 1 < i < n. 

(1) A randomly splits her integers rrn in a sum of two integers: rrn = ri + S{. 

(2) A sends the (ordered) set of all rj, 1 < i < n, to D, and the (ordered) set of all 
Si, 1 < i < n, to B. 

(3) B sends to D the set of indices ji, ■ ■ ■ ,jk corresponding to the messages mj he 
wants to receive. 

(4) D sends to B the (ordered) set Tj x , ■ ■ ■ , r,j k . 

(5) B recovers mj 1 , . . . , rrij k as a sum of relevant rj and Sj. 

9. Mental poker 

"Mental poker" is the common name for a set of cryptographic problems that con- 
cerns playing a fair game over distance without the need for a trusted third party. One 
of the ways to describe the problem is: how can 2 players deal cards fairly over the 
phone? Several protocols for doing this have been suggested, including [IT], [5], [9] 
and p]. As with the bit commitment, it is rather obvious that a fair card dealing to 
two players over distance is impossible without a one-way function, or even a one-way 
function with trapdoor. However, it turns out to be possible if the number of players 
is at least 3, assuming, of course, that there are secure channels for communication 
between at least some of the players. In our proposal, we will be using k secure chan- 
nels for k > 3 players P\, . . . ,Pfc, and these k channels will be arranged in a circuit: 

To begin with, suppose there are 3 players: Pi, P2, and P3 and 3 secure channels: 
P 1 ^P 2 ^P 3 ^P l . 

The first protocol, Protocol 1 below, is for distributing all integers from 1 to m to 
the players in such a way that each player gets about the same number of integers. 
(For example, if the deck that we want to deal has 52 cards, then two players should 
get 17 integers each, and one player should get 18 integers.) In other words, Protocol 
1 allows one to randomly split a set of m integers into 3 disjoint sets. 

The second protocol, Protocol 2, is for collectively generating random integers mod- 
ulo a given integer M. This very simple but useful primitive can be used: (i) for 
collectively generating, uniformly randomly, a permutation from the group S m . This 
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will allow us to assign cards from a deck of m cards to the m integers distributed by 
Protocol 1; (ii) introducing "dummy" players as well as for "playing" after dealing 
cards. 

9.1. Protocol 1. For notational convenience, we are assuming below that we have to 
distribute integers from 1 to r = 3s to 3 players. 

To begin with, all players agree on a parameter N, which is a positive integer of a 
reasonable magnitude, say, 10. 

(1) each player Pj picks, uniformly randomly, an integer (a "counter") Cj between 
1 and N, and keeps it private. 

(2) Pi starts with the "extra" integer and sends it to P^. 

(3) P2 sends to P3 either the integer m he got from Pi, or m + 1. More specifically, 
if P2 gets from Pi the same integer m less than or equal to C2 times, then he 
sends m to P3; otherwise, he sends m + 1 and keeps m (i.e., in the latter case m 
becomes one of "his" integers). Having sent out m + 1, he "resets his counter", 
i.e., selects, uniformly randomly between 1 and N, a new c-i- He also resets his 
counter if he gets the number m for the first time, even if he does not keep it. 

(4) P3 sends to Pi either the integer m he got from P2, or m + 1. More specifically, 
if P3 gets from P2 the same integer m less than or equal to C3 times, then he 
sends m to Pi; otherwise, he sends m + 1 and keeps m. Having sent out m + 1, 
he selects a new counter C3. He also resets his counter if he gets the number m 
for the first time, even if he does not keep it. 

(5) Pi sends to P2 either the integer m he got from P3, or m + 1. More specifically, 
if Pi gets from P3 the same integer m less than or equal to c\ times, then he 
sends m to P2; otherwise, he sends m + 1 and keeps m. Having sent out m + 1, 
he selects a new counter c±. He also resets his counter if he gets the number m 
for the first time, even if he does not keep it. 

(6) This procedure continues until one of the players gets s integers (not counting 
the "extra" integer 0). After that, a player who already has s integers just 
"passes along" any integer that comes his way, while other players keep following 
the above procedure until they, too, get s integers. 

(7) The protocol ends as follows. When all 3s integers, between 1 and 3s, are 
distributed, the player who got the last integer, 3s, keeps this fact to himself 
and passes this integer along as if he did not "take" it. 

(8) The process ends when the integer 3s makes N + 1 "full circles" . 

We note that the role of the "extra" integer is to prevent P3 from knowing that P2 
has got the integer 1 if it happens so that C2 = 1 in the beginning. 

We also note that this protocol can be generalized to arbitrarily many players in 
the obvious way, if there are k secure channels for communication between k players, 
arranged in a circuit. 

9.2. Protocol 2. Now we describe a protocol for generating random integers modulo 
some integer M collectively by 3 players. As in Protocol 1, we are assuming that there 
are secure channels for communication between the players, arranged in a circuit. 



11 



SECRECY WITHOUT ONE-WAY FUNCTIONS 



(1) Pi and P3 uniformly randomly and independently select private integers 77,2 and 
77,3 (respectively) modulo M. 

(2) P2 sends 77,2 to Pi, and P3 sends 713 to P\. 

(3) Pi computes the sum m = 112 + 77,3 modulo M. 

Note that neither P2 nor P3 can cheat by trying to make a "clever" selection of their 
rii because the sum, modulo M, of any integer with an integer uniformly distributed 
between and M — 1, is an integer uniformly distributed between and M — 1. 

Finally, Pi cannot cheat simply because he does not really get a chance: if he miscal- 
culates 772+773 modulo M, this will be revealed at the end of the game. (All players keep 
contemporaneous records of all transactions, so that at the end of the game, correctness 
could be verified.) 

To generalize Protocol 2 to arbitrarily many players Pi,... , Pfc, k > 3, we can just 
engage 3 players at a time in running the above protocol. If, at the same time, we want 
to keep the same circular arrangement of secure channels between the players that we 
had in Protocol 1, i.e., Pi — >■ P2 — >■ . . . P& — > Pi, then 3 players would have to be Pj+i, 
Pi, Pj+2, where i would run from 1 to k, and the indices are considered modulo k. 

Protocol 2 can now be used to collectively generate, uniformly randomly, a permu- 
tation from the group S m . This will allow us to assign cards from a deck of m cards 
to the m integers distributed by Protocol 1. Generating a random permutation from 
S m can be done by taking a random integer between 1 and m (using Protocol 2) se- 
quentially, ensuring that there is no repetition. This "brute-force" method will require 
occasional retries whenever the random integer picked is a repeat of an integer already 
selected. A simple algorithm to generate a permutation from S m uniformly randomly 
without retries, known as the Knuth shuffle, is to start with the identity permutation 
or any other permutation, and then go through the positions 1 through (m — 1), and 
for each position i swap the element currently there with an arbitrarily chosen element 
from positions i through m, inclusive (again, Protocol 2 can be used here to produce 
a random integer between i and m). It is easy to verify that any permutation of m 
elements will be produced by this algorithm with probability exactly — f, thus yielding 
a uniform distribution over all such permutations. 

After this is done, we have m cards distributed uniformly randomly to the players, 
i.e., we have: 

Proposition 1. If m cards are distributed to k players using Protocols 1 and 2, then 
the probability for any particular card to be distributed to any particular player is \. 

9.3. Using "dummy" players while dealing cards. We now show how a combina- 
tion of Protocol 1 and Protocol 2 can be used to deal cards to just 2 players. If we have 
2 players, they can use a "dummy" player (e.g. a computer), deal cards to 3 players as 
in Protocol 1, and then just ignore the "dummy" 's cards, i.e., "put his cards back in 
the deck" . We note that the "dummy" in this scenario would not generate randomness; 
it will be generated for him by the other two players using Protocol 2. Namely, if we 
call the "dummy" P3, then the player Pi would randomly generate C31 between 1 and 
./V and send it to P3, and Pj would randomly generate C32 between 1 and N and send 
it to P3. Then P3 would compute his random number as C3 = C31 + C32 modulo N. 
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Similarly, "dummy" players can help k "real" players each get a fixed number s of 
cards, because Protocol 1 alone is only good for distributing all cards in the deck to 
the players, dealing each player about the same number of cards. We can introduce m 
"dummy" players so that (m + k) ■ s is approximately equal to the number of cards in 
the deck, and position all the "dummy" players one after another as part of a circuit 
Pi — > P2 — > ■ ■ ■ P m +k — > Pi- Then we use Protocol 1 to distribute all cards in the deck 
to (m + k) players taking care that each "real" player gets exactly s cards. As in the 
previous paragraph, "dummy" players have "real" ones generate randomness for them 
using Protocol 2. 

After all cards in the deck are distributed to (m + k) players, "dummy" players send 
all their cards to one of them; this "dummy" player now becomes a "dummy dealer" , 
i.e., he will give out random cards from the deck to "real" players as needed in the 
course of a subsequent game, while randomness itself will be supplied to him by "real" 
players using Protocol 2. 

10. Summary of the properties of our card dealing (Protocols 1 and 2) 

Here we summarize the properties of our Protocols 1 and 2 and compare, where 
appropriate, our protocols to the card dealing protocol of pQ. 

1. Uniqueness of cards. Yes, by the very design of Protocol 1. 

2. Uniform random distribution of cards. Yes, because of Protocol 2; see our 
Proposition 1 in Section [9. 2i 

3. Complete confidentiality of cards. Yes, by the design of Protocol 1. 

4. Number of secure channels for communication between k > 3 players: k, 

arranged in a circuit. 

By comparison, the card dealing protocol of pQ requires 3k secure channels. 

5. Average number of transmissions between k > 3 players: 0(^mk), where 
m is the number of cards in the deck, and N « 10. This is because in Protocol 1, 
the number of circles (complete or incomplete) each integer makes is either 1 or the 
minimum of all the counters Cj at the moment when this integer completes the first 
circle. Since the average of q is at most we get the result because within one circle 
(complete or incomplete) there are at most k transmissions. We note that in fact, there 

J2 N - j k 

is a precise formula for the average of the minimum of c, in this situation: — ^ — , 
which is less than y if k > 2. 

By comparison, in the protocol of [1] there are 0(mk 2 ) transmissions. 

6. Total length of transmissions between k > 3 players: ^-mk -log 2 r7i bits. This 
is just the average number of transmissions times the length of a single transmission, 
which is a positive integer between 1 and m. 

By comparison, total length of transmissions in pQ is 0(mk 2 log k). 

7. Computational cost of Protocol 1: (because there are no computations, only 
transmissions) . 
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By comparison, the protocol of pQ requires computing products of up to k permuta- 
tions from the group Sk to deal just one card; the total computational cost therefore 
is 0(mk 2 log k). 

11. Secret sharing 

Secret sharing refers to method for distributing a secret amongst a group of partici- 
pants, each of whom is allocated a share of the secret. The secret can be reconstructed 
only when a sufficient number of shares are combined together; individual shares are 
of no use on their own. 

More formally, in a secret sharing scheme there is one dealer and k players. The 
dealer gives a secret to the players, but only when specific conditions are fulfilled. The 
dealer accomplishes this by giving each player a share in such a way that any group of 
t (for threshold) or more players can together reconstruct the secret but no group of 
fewer than t players can. Such a system is called a (t, /c)-threshold scheme (sometimes 
written (A;, t)-threshold scheme). 

Secret sharing was invented by Shamir [TB] and Blakley [2], independent of each other, 
in 1979. Both proposals assumed secure channels for communication between the dealer 
and each player. In our proposal here, the number of secure channels is equal to 2k, 
where k is the number of players, because in addition to the secure channels between 
the dealer and each player, we have k secure channels for communication between the 
players, arranged in a circuit: Pi — > P2 — > . . . — > Pk — > Pi ■ 

The advantage over Shamir's and other known secret sharing schemes that we are 
going to get here is that nobody, including the dealer, ends up knowing the shares (of 
the secret) owned by any particular players. The disadvantage is that our scheme is a 
(k, £;)-threshold scheme only. 

We start by describing a subroutine for distributing shares by the players among 
themselves. More precisely, k players want to split a given number in a sum of k 
numbers, so that each summand is known to one player only, and each player knows 
one summand only. 

11.1. The Subroutine (distributing shares by the players among themselves). 

Suppose a player Pj receives a number M that has to be split in a sum of k private 
numbers. In what follows, all indices are considered modulo k. 

(1) Pi initiates the process by sending M — mi to p+i, where m; is a random 
number (could be positive or negative). 

(2) Each subsequent Pj does the following. Upon receiving a number m from Pj-i, 
he subtracts a random number rrij from m and sends the result to Pj+i- The 
number m, is now P,'s secret summand. 

(3) When this process gets back to p, he adds rrn to whatever he got from Pj_i; 
the result is his secret summand. 

Now we get to the actual secret sharing protocol. 
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11.2. The protocol (secret sharing (k, /c)-threshold scheme). The dealer D wants 
to distribute shares of a secret number N to k players P so that, if Pi gets a number 
Si, then Ya=i s i = N - 

(1) D arbitrarily splits N in a sum of k integers: N = Yli=i n i- 

(2) The loop: at Step i of the loop, D sends rn to Pj, and Pi initiates the above 
Subroutine to distribute shares of nj among the players, so that Ylj=i n ij = 

m. 

(3) After all k steps of the loop are completed, each player p ends up with 
numbers riji that sum up to Sj = 5^j=i ^ * s obvious that 5Zi=i s « = ^ ■ 
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